On startup SCR will blast change count updates for each
component it satisfies and activates etc.

This resulted in a very large number of task being submitted
to the scheduled executor.  Prior to using an executor a Timer
was used.  In both cases the tasks would wait a default of 5
seconds before updating the change count service property.

Every task submitted would be a no-op except the very last one
which had the "final" change count value.  This behavior is
to avoid flooding the system with service modified events.

The issue is that now we are flooding the scheduled executor
with a significant number of task that most all do nothing.
Since moving to an executor we noticed a non-trivial bump in
our CPU usage when the default 5 seconds passes to run all
the queued tasks.

It turns out that on the JVM we are using the Timer is actually
more efficient than the scheduled executor for popping off
all the tasks and running them when the delay timeout is hit.

The overall design here is sub-optimal regardless.  Flooding
a queue with all but one task that do nothing is not efficient.
This change moves to using a simple repeating task that just
updates the change count service property, if needed, every
delay period (defaults to every 5 seconds).